Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compute latest snapshot directly in TransportGetShardSnapshotAction #76254

Merged
merged 4 commits into from
Aug 11, 2021

Conversation

fcofdez
Copy link
Contributor

@fcofdez fcofdez commented Aug 9, 2021

As discussed in #75840 now we compute the latest snapshot directly in TransportGetShardSnapshotAction and GetShardSnapshotResponse just contains the latest snapshot for the shard.
I used the snapshotId as a tiebreaker for the snapshot ordering, even though I think that should be rare enough outside of tests.

Relates #73496

@fcofdez fcofdez added :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. v8.0.0 Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.15.0 labels Aug 9, 2021
@fcofdez fcofdez marked this pull request as ready for review August 10, 2021 09:49
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

@fcofdez fcofdez requested a review from DaveCTurner August 10, 2021 09:50
Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

for (String workingRepoName : workingRepoNames) {
createSnapshot(workingRepoName, "empty-snap", Collections.singletonList(indexName));
latestSnapshot = createSnapshot(workingRepoName, "empty-snap-" + snapshotIdx++, Collections.singletonList(indexName));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with giving all the snapshots unique names, but I'm curious whether this was necessary (and why).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These snapshots can take a short time to finish and some might overlap, in that case we need some tie breaker and I decided to use the name.

@fcofdez
Copy link
Contributor Author

fcofdez commented Aug 10, 2021

@elasticmachine update branch

@fcofdez
Copy link
Contributor Author

fcofdez commented Aug 10, 2021

@elasticmachine run elasticsearch-ci/part-1
(Unrelated failure)

@fcofdez
Copy link
Contributor Author

fcofdez commented Aug 10, 2021

@elasticmachine run tests

@fcofdez
Copy link
Contributor Author

fcofdez commented Aug 11, 2021

@elasticmachine update branch

@fcofdez fcofdez added the auto-backport Automatically create backport pull requests when merged label Aug 11, 2021
@fcofdez fcofdez merged commit ca1f4dd into elastic:master Aug 11, 2021
@fcofdez fcofdez added backport pending auto-backport Automatically create backport pull requests when merged and removed auto-backport Automatically create backport pull requests when merged labels Aug 11, 2021
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Aug 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Automatically create backport pull requests when merged :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. >enhancement Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.15.0 v8.0.0-alpha2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants